Defining the State Diagram

The State Diagram is what its name states: your information can be another way to describe the states of your domain. For instance, it is about  “FetchingTheMail”.

If the State attribute isn't shown on the “Class” icon, then we need to add some small widgets to see that. If this hasn’t been done automatically, do it manually on the functions by adding the “TagExtensions”. The TagExtensions show up as a dialogue - we will ensure the default TagExtension:

• "statediagramsymbol"
• "triggermethod"
• "constraintclass"

Since the tag extensions have a WPF xaml definition, we can add a new symbol easily, patching some xaml that is preferred to view.

Once we have done that, we can use the extensions for different things. In our case, if we take a look at the diagram, there is a little widget that appeared, stating the "S" for the State Diagram.

This is a sort of coverage of the different types of diagrams that are available in MDriven Designer. Everything works the same way. If you point at something, it is selected and you could change some properties in the proper field or the name of the class to "House". Either standing on the actual “Class” name and pressing f2/double clicking to edit, as well. Moving around with the arrow signs and arrow characters helps to navigate the model easily or rather, use a mouse. In addition, you can select many to move them in together.

For instance, the "House" has several attributes. You would go about adding an attribute (Ctrl+A) and edit those in place, just by double-clicking to make it changeable to "Address". An attribute needs to have a type. As we point to the "Address”, the possible types are available in the Object Inspector picker. These are the types that are available for you if you are going to execute your modeling, Turnkey.

Associations

All the classes, that you add also turn into types, but the model type isn't used as an attribute type. It's instead called an Association. These can be created just by picking the Association mode tool and dragging between two classes. Noteworthy is that though the class is in the package, it's not really on the diagram, as the last one is just a way to show that class. If we were to switch the diagram back to the other one, you can see that since this shows the same class, it also shows the same attributes as we added many. After adding even more attributes, it will also be visible on the other diagram.

What can you do if you don’t want that? Right-click on a class, say "Features", where the “Show features” is checked. We can also choose what features we want to be shown on the current diagram. Clicking “Pick show features…” brings up the dialog "Featurepickform". Here we can state what mode it should be (show all, show only picked, hide only picked, or hide all). Go on choosing "show only the picked” one and pick the "Address" and the “State” - it will appear on the Picked Attributes side as well as on the overview screen. This doesn't mean that the rest of the attributes aren't available. As you see in the repository, they are still there, but we have chosen not to show them on this screen. At the same time on the other diagram, you are still there.

This is a way to design your diagrams to focus on a single issue that you want to describe. You could also give the placed classes a colour on the screen that differs from the default. Choosing this option in Object Inspector, let's pick a blue one for the “House” in the current diagram. However, sometimes we want any "House" class to have a certain colour and then we can instead set the default colour on the class. In the first case, the blue “House” stayed the same colour, because it's what we explicitly told it to be. However, we can also see that it has been set with the default colour as gold. If we were to clear the blue one out, it will turn gold. This is one way to give your model colour.

Deciding what to show on the diagram, you could right-click on the class and say "Features", or "Pick show features". A shorthand for this is just standing on the attribute and pressing "Delete". Though you might think that this would actually remove or delete the attribute from the repository, that is not the case. What happened was that the "Features", " Pick show features" and then the "Featurepickform" has been updated to remove the ones that I am uninterested in.

What if we actually want to delete “Attribute1”?

Then we have to press "Ctrl+Delete" - "Delete" most often stands for hiding from view. For instance, if we want to "Delete" this class, select it and press "Delete". It will disappear but still be in the repository, so we can get it back that way to actually remove it. Again, it's "Ctrl+Delete". Now press the "Edit”, and ”Undo"  to get it back.

If we drag on another class to the diagram one, that actually has a relation to the "House" that will be shown. I can also drag on the "House" one more time and repeat the process on the overview screen. The common use case for this is actually when your diagram is large and maybe "House" is just a peripheral class to something that needs to be shown in various locations. It would be good to be able to duplicate it and show it in many places.

Maybe you don't want the associations to show. Let's say, that we have another class and we call that "Street. We create an association between "Street" and "House". How come there's no association between the other “House”s in the diagram? That was because the "House" class came into this diagram before the "Street" even existed. If we were to remove this with "Delete" and add it again, then it would be there, and the rest is optional.

In case you want to "View or not" associations, just press "Delete" to remove them from view and “Ctrl+Delete" to actually delete them. In addition, having selected "Undo", we will get them back. If it needs to remove from the view in this location, just press "Delete".

Let's have that deleted, and at this point, both classes lack the association to "Street" in this diagram By filtering the repository with the "House" we can see:

• "House" the class
• "House" attribute 10

" Attribute ":

• everything that matches "attribute" and isn't a class

". House":

• all the association ends that are named "House"

"Street":

• "Street" the class
• "House" -  the "Street" association name
• "Street" – the "House" association name

Of course, these options are selectable; we are able to set the properties and they are all in the Object Inspector field. Press "Esc" to clear the filter search and get back to the repository tree - all the things are available on the screen, as well.

If we want to reintroduce associations, right-click and say "Introduce and remove", where "Introduce pick from available"  says "House".  However “House" is already on the diagram, so it won’t be able to do it. For instance, we removed the association between the “Street” and the “House” classes. By using the "Re-introduce removed associations" option, we can get it back.

Associations have the anchor points on their classes, so it should be possible to design your diagrams. Grabbing an association introduces via points. It is recommended to use the square line option that is intended to do things in 90 degrees for a more clean and manageable design. This is so common. By clicking the backside to get the properties of the diagrams in the Object Inspector, set it to “square new associations” - all associations will be defaulted to squared.

There are smaller options on the diagram. Right-clicking backside shows "association names", which we need to set to "DimDefaults". What we mean by this action is that this dimmed "Street" and the "House", because these haven't actually been given hard names, because of what they are pointing at. Another two options for “show association names” besides “DimDefault”:

• “AlwaysEvenDefaults" leads to hard black all the aspects of the associations.
• Ability to show and tell the diagram to not draw the defaults at all –“NoDefaults”.

When you have a little model, it is important to save it. Creating and saving the file to e.g. c:\temp\demo55, there are two ways for the system to treat it:

• Saving as a “modlr” file → will be treated as one zip file, where we can see all the parts in it;
• Saving as an "ecomdl" file → format and this is saved  as the individual parts, so then we get all the parts and each of them is well-formed XML

Take a look at the "association" tool that helps you combine things together with associations and where you can set the cordiality on the ends. It is also manageable on the property inspector, or do manual editing by writing something on the ends like: "*" or "1" or "0..1" House”. Immediately we see the "e" (stands for embed) to pop up. Usually, there is a “many-to-one” side of an association - in this case, this side will actually store the key to this single object. The key is where the association is embedded in this class. What if we need to get keys for a one-to-one association? This is why we write it out explicitly, but this is considered more or less an error because it's redundant to embed the key both in "House" pointing out the "Street" as well as in the "Street" pointing out the "House". We need to choose one that actually embeds and removes the embed from the other one, manually.

It’s more convenient to use when the "House" has 0..1 "Street", but the "Street" can have multiple "House"s. In fact, it might be a good practice to have the default name of this. This is now named "House", but maybe it would be better to put a plural "s" on all their multilinks - that would make the default associations a bit more correct.

We can actually set the property on the package, remembering that all our classes belong to one package, "Package1" in this case and there's a property called "PluralSuffix", so is there anything? Our goal is to append the suffix “s” to everything that all associations end with. If it seems insufficient, you can always overwrite it with a specific name.

Heading back to the overview screen now, we want to focus on looking for something special among all the diagrams. You can always turn on the magnifier - there's a looking glass - that is held over the diagrams to find the details or locate things.

Here is the overview of all the diagrams, but in this way, we also can manage all the classes and their relations that are currently in the model, information, actions, and even the 3D view if it is necessary to do so. This is pretty much a work in progress as we figure out how best to use it.

What about the generalization/specialization mode?

Let’s create a base class or superclass for "Street" called "Location", and "Street" is a type of “Location”. So "Street" is then a specialization of "Location". Taking a generalization arrow, drag it from "Street" to “Location”, because, in this direction, things get more specialized. The next step is a property for “Location” called “Position” - logically, the "Street" actually inherits the attributed "Position".

How does the association class connection mode work?

This is commonly used if you have many-to-many relations where the key is not embedded on any side because there can be many classes for each of them. What we'll need to be done logically is to introduce a link class in this association. Clicking the association, we have an option of picking its specific class to say that this is the Association class. it is also manageable with the association connection tool. Dragging the arrow tool, we get a dotted line which means the setting of the association classes. You can control the ”Association Class” tool factors from the Property Inspector where:

• If we null it -  the dotted line will disappear
• If we add it again - the dotted line will not be introduced, because that would be the same as we had removed it by hand, so go to the "Introduce and remove", and "Reintroduce removed associations".

Introducing some of the other toolbar items

The reference window is just to get a read-only copy of one of your diagrams if you need to compare something from one diagram with another and you want to see them side-by-side. it might be good to have multiple diagrams on the screen at the same time.

"Index model and report errors..." actually runs through the model to check that everything seems fine it checks all the expressions we may have in our model.

There was the question about what the "Default String Representation" of the “House” is. If we would do this by writing a small OCL object constraint language expression, we would be in the context of "House" and we would use the Address "self.Address". Then the expression would be there. If we check, it's fine, but should the expression be something different - that is not an available property. We would get an error indicator saying that the "Default String Representation" on "House" is not a member of "House". Since this is in error, when we bring it up to the editor, we will also see that "AddressX" is not a member of "House".  For now, it is enough to fix this error by removing the "X". However, there are also other ways to do it through the OCL (object constraint language expression).

Enterprise Architect Information

With the help of the “Enterprise Architect Information" window, we can add processes and how they connect to each other. We can have and add "entries", and "catalogue entries" that aren't really classes but are more concepts that we use our classes to fulfill. For instance, one concept might be "Place to live" and the "House" implements “place to live". Tying things together will bring further information on the classes.

The "Actors" are "Mailman" and "Home Owner", and you can add a "motivation" or “user story” for the actors as well. This can also be implemented by one of the steps in our processes.

As we go deeper down on the Enterprise Architect Information window, we have the “Applications”. What we actually have in our enterprise are the tools for people in the enterprise to use, and for the actors to manage. That’s the whole point of the apps. The applications need some kind of infrastructure.

These are the core concepts of the "Enterprise Architecture Information"

• How infrastructure relates to applications
• How applications are used in processes by actors
• How they all work on information
• How the information is tied to and implemented by classes

We will see that all of these things tie together in the end, such that you will have a complete understanding and documentation of all the things that you choose to model.